Fix string representation of values in settings panel #2263
Conversation
federicobond
force-pushed
the
fix-settings
branch
from
b2d1c6e to
bb7ab54
Compare
matthiask
left a comment
matthiask
left a comment
There was a problem hiding this comment.
LGTM.
Can you show an example of how it looks now?
debug_toolbar/panels/settings.py
Outdated
| { | ||
| "settings": { | ||
| key: force_str(value) | ||
| key: pformat(value) |
There was a problem hiding this comment.
Are you sure that force_str can just be removed? I think we added that to not crash when value contains binary data or something. Maybe pformat handles that just fine.
There was a problem hiding this comment.
Not sure. It should return a string for most well-behaved objects but I can wrap it so it tolerates exceptions.
There was a problem hiding this comment.
It has just been added here: https://github.com/django-commons/django-debug-toolbar/pull/2217/files
The bytes.fromhex value would probaly be a good test for this change.
There was a problem hiding this comment.
pprint.pformat would format that bytes value as:
(b'\xa3\xf2\xb8\xc1N\x97-Z\x8f\xb3\xc7)\x1ad\xe0\x85\x9cG+\xf6=\x18\xa0\x94'
b'^s\xb2\xc8O\x91z\xe2')
instead of "Django Debug Toolbar was unable to parse value."
docs/changes.rst
Outdated
| ``debug_toolbar.store.DatabaseStore`` with ``SKIP_TOOLBAR_QUERIES``. | ||
| * Fixed font family for code blocks and stack traces in the toolbar. | ||
| * Added test to confirm Django's ``TestCase.assertNumQueries`` works. | ||
| * Fixed display of values in settings panel. |
There was a problem hiding this comment.
Maybe more specific? Not sure if that's an improvement, just a suggestion.
| * Fixed display of values in settings panel. | |
| * Fixed double quoting of values in settings panel. |
There was a problem hiding this comment.
Would this work better?
Fixed string representation of values in settings panel
There was a problem hiding this comment.
@matthiask I've updated the commit message to be more specific. Let me know what you think.
Coverage report
Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||||||||
|
@matthiask the attached screenshot shows how it looks with this change. I added one with the current behavior just below. |
I'm sorry if I'm being dense but I only see one screenshot? |
federicobond
force-pushed
the
fix-settings
branch
from
bb7ab54 to
105b605
Compare
|
How about now? |
federicobond
force-pushed
the
fix-settings
branch
from
105b605 to
3e83c1f
Compare
federicobond
changed the title
federicobond
force-pushed
the
fix-settings
branch
from
3e83c1f to
c0845b8
Compare
|
|
||
| def safe_pformat(obj): | ||
| try: | ||
| return pformat(obj) |
There was a problem hiding this comment.
I'm wondering if maybe we should roll this into force_str as force_str(pretty=True)?
There was a problem hiding this comment.
I don't think they have the same semantics. In this case, for example, I would very much like to distinguish False (bool) from "False" (str), and b"Foo" (bytes) from "Foo" (str).
force_str map the first two into False and the other two into Foo, thus losing that important information.
3 participants
Description
There was some weird double quoting going on in the settings panel values column. This fixes the formatting so it's more consistent and clearly distinguishes string from non-string values. Added some tests for the new behavior.
Before
After
Checklist:
docs/changes.rst.